I. Stackable Devices and Stacking Systems
As known in the art, a “stackable device” is a network device (typically an L2/L3 switch) that can operate independently as a standalone device or in concert with one or more other stackable devices in a “stack” or “stacking system.” FIG. 1A illustrates the front face of an exemplary stackable device 100 according to an embodiment. As shown, stackable device 100 includes a set of data ports 102, a set of stacking ports 104, and a console port 106. Data ports 102 are operable for connecting stackable device 100 to one or more hosts and/or data networks. Stacking ports 104 are operable for linking stackable device 100 (via “stacking links”) to other devices in the same stacking system/topology. Unlike data ports 102, stacking ports 104 are considered internal ports (like a switching fabric in a chassis-based switch) and thus only forward packets within the stacking system. Stacking ports 104 can be dedicated ports (i.e., ports designed specifically for stacking) or high bandwidth data uplink ports that operate in a stacking mode. Console port 106 is operable for accessing the management console of stackable device 100 in order to perform various device management functions.
FIG. 1B illustrates an exemplary stacking system 120 according to an embodiment. As shown, stacking system 120 comprises a number of stackable devices 122, 124, and 126 (each similar to stackable device 100 of FIG. 1A) that have been linked together via their respective stacking ports. In the example of FIG. 1B, stackable devices 122, 124, and 126 form a ring topology. In addition, stackable device 124 is designated as the “master” device of stacking system 120, which means that stackable device 124 serves as the point of user contact for all management functions of system 120. For instance, stackable device 124 can accept and process user commands directed to the overall configuration of stacking system 120. Stackable device 124 can also communicate with non-master devices 122 and 126 as needed in order to propagate various types of management commands and data to those devices.
Most stacking systems in use today support linear or ring topologies, like the ring shown in FIG. 1B. However, advanced stacking systems, such as those implementing Brocade Communication Systems' “HyperEdge” technology, can support general mesh-like topologies (e.g., star, tree, partial mesh, full mesh, etc.), which allow for improved resiliency and shorter latency. Advanced stacking systems can also mix high-end and low-end stackable devices in a single topology. For example, FIG. 1C depicts an advanced stacking system 140 comprising a combination of high-end devices 142-148 and low-end devices 150-156 that are interconnected in the form of a partial mesh. In this example, the stacking ports of high-end devices 142-148 support higher data throughput than the stacking ports of low-end devices 150-156. For instance, the stacking ports of high-end devices 142-148 may be 100G ports, while the stacking ports of low-end devices 150-156 may be 10G or 40G ports. Accordingly, the stacking links directly interconnecting high-end devices 142-148 to each other (as shown by heavy lines) have higher bandwidth than the stacking links directly interconnecting low-end devices 150-156 to each other or to high-end devices 142-148 (as shown by light lines).
II. Broadcast/Multicast Packet Switching in Stacking Systems
Generally speaking, the data packets that are switched/forwarded by a stacking system can be classified into three types based on their respective destinations: (1) unicast, (2) broadcast, and (3) multicast. A unicast packet is directed to a single destination. Thus, when a unicast packet is received at an ingress data port of a stacking system, the unicast packet need only be switched through the stacking ports needed to deliver the packet to a single egress data port (of a single stackable device) in the system.
On the other hand, broadcast and multicast packets are directed to multiple destinations; in particular, a broadcast packet is directed to all nodes in the packet's VLAN, while a multicast packet is directed to certain, selective nodes (comprising a multicast group) in the packet's VLAN. Thus, when a broadcast or multicast packet is received at an ingress data port of a stacking system, the broadcast/multicast packet must generally reach, or be capable of reaching, every stackable device in the system that has egress data ports in (i.e., are members of) the packet's VLAN.
This gives rise to two potential problems. First, if an incoming broadcast/multicast packet is simply flooded throughout a stacking system (i.e., replicated to each stacking port) so that it can reach every stackable device in the system, the flooded packets may endlessly loop through the system's topology (assuming the topology is a ring or a mesh with looping paths). Fortunately, it is possible to avoid packet looping by implementing a feature known as “egress source ID filtering.” With this feature, each ingress packet is tagged with a source ID that identifies the stackable device on which the packet was received. In addition, a set of single-source spanning trees originating from each stackable device is calculated. The single-source spanning trees are then used to filter packets at the system's stacking ports in a manner that ensures a packet with a particular source ID is only switched along the paths of its corresponding tree. This effectively eliminates packet looping, while allowing each stackable device to be reachable from every other device in the system.
The second problem is that, even with egress source ID filtering in place, a broadcast/multicast packet may still be replicated to stackable devices in the system that do not need to receive the packet (i.e., do not have any data ports in the packet's VLAN). To better understand this, note that a data packet is generally received at an ingress data port of a stacking system, forwarded through the system's stacking ports, and then output via one or more egress data ports. In order for the packet to be allowed through the data and stacking ports in this forwarding path, each data/stacking port must be associated with (i.e., considered “in”) the packet's VLAN (via a “VLAN association”). For example, if the packet reaches a stackable device in the system via an input port (either data or stacking) that is not in the packet's VLAN, the packet will be dropped. Similarly, if a stackable device attempts to send out the packet via an output port (either data or stacking) that is not in the packet's VLAN, the transmission will be blocked.
However, with current stacking implementations, it is difficult to determine the appropriate VLAN associations for every stacking port in a complicated topology. For instance, a stackable device that has no data ports in a particular VLAN may still need to bridge that VLAN via one or more of its stacking ports for a stackable device that is several hops away. Thus, the common practice is to associate every possible VLAN to every stacking port in the system. This will cause an incoming broadcast/multicast packet to be replicated to every stacking port regardless of the packet's VLAN (as long as it is not blocked by egress source ID filtering), and thus result in transmission of the broadcast/multicast packet to every stackable device in the system, even if certain devices do not need it.
The foregoing practice wastes stacking port bandwidth, which can be particularly problematic in large stacking systems, or advanced stacking systems that have stacking ports/links of differing bandwidths. For example, in advanced stacking system 140 of FIG. 1C, unnecessary broadcast/multicast traffic can quickly saturate the links interconnecting low-end devices 150-156 to each other (and to high-end devices 142-148) due to their relatively low bandwidth capacities.